Computer systems that provide users access to limited resources are well known. For example, a client-server system represents a common paradigm for providing shared access to a limited resource such as a computer database on a server. The typical client-server system includes a computer (the "server") in which one or more limited resources reside (e.g., are stored) and one or more satellite computers (the "clients") which access the limited resources. The access is generally performed over an electronic communication system. The clients access the limited resources on an as needed basis.
A server typically includes a computer or multiple computers connected via an electronic communication system, services (e.g., a data service that provides access to a database residing in a computer or a distributed service residing in multiple computers connected via an electronic communication system), and a storage for storing the services. The storage typically includes some combination of random access memory ("RAM") and magnetic media, such as tapes and disks or optical media, and other storage devices. Depending on the requirements of the system, the server may be a personal desktop computer that includes a hard-disk, a large mainframe computer that includes multiple tape drives, or some other kind of computer.
A client may be a personal computer, a workstation, or some other kind of computer. A client may be either remote from the server (i.e., the client accesses the server via an electronic communication system) or local to the server (e.g., the client accesses the server via a local bus). A client may include one or more "applications" such as a word processor, a web browser, or database interface software to access information from a database on a server. Some of the applications may be under the control of a human operator and others may run automatically or under the control of another application.
An electronic communication system ("network") may include commercial telephone lines as well as dedicated communication lines to carry data signals between the server and the client.
Prior client-server approaches allow a limited number of clients to access limited resources residing in a server. In particular, in the typical client-server environment, the workload characteristics are predictable and well known because of the predetermined limit on the number of clients and the well known nature of the clients.
However, increasing Internet usage presents a unique problem for providing a dramatically increasing and unpredictable number of clients efficient and fair allocation of access to limited resources residing in a server. Accordingly, prior client-server approaches are inadequate for the Internet environment, because the number of concurrent users in the Internet environment generally exceeds the number of concurrent users in a typical client-server environment and is generally more unpredictable.
A Common Object Request Broker Architecture (CORBA) represents a partial attempt to address the problem of providing an increasing and unpredictable number of users access to limited resources residing in a server. CORBA provides a client/server middleware defined by an industry consortium called the Object Management Group (OMG), which includes over 700 companies representing the entire spectrum of the computer industry.
In particular, CORBA defines an implementation-independent component-based middleware. CORBA allows intelligent components to discover each other and interoperate on an object bus called an Object Request Bus (ORB). CORBA objects can reside anywhere on a network. Remote clients can access a CORBA object via method invocations. Clients do not need to know where a CORBA object resides or on which operating system the CORBA object is executed. Thus, a client can access a CORBA object that resides in the same process or on a machine in another country connected via the Internet.
Further, both the language and compiler used to create CORBA objects are transparent to clients. For example, a CORBA object may be implemented as a set of C++ classes, in JAVA bytecode, or in COBOL code. Thus, the implementation of the CORBA object is irrelevant to the client. The client only needs to know the interface of the CORBA object. CORBA uses an Interface Definition Language (IDL) to define a CORBA object's interface, and the IDL also allows for specifying a component's attributes such as the parent classes it inherits from and the methods its interface supports. For example, a CORBA object provides an implementation for the CORBA object's IDL interface using a language for which an IDL mapping exists. In particular, CORBA defines a standard mapping from the IDL to other implementation languages such as C++, JAVA, ADA, etc.
A CORBA IDL compiler generates client-side stubs and server-side skeletons for the CORBA object's IDL interface.
CORBA also specifies bus-related services for creating and deleting objects, accessing them by name, storing them in persistent stores, externalizing their states, and defining ad hoc relationships between them. Accordingly, CORBA provides a flexible distributed-object middleware that provides client-server interoperability. CORBA and JAVA are both further described in "Client/Server Programming with JAVA.TM. and CORBA" by Robert Orfali and Dan Harkey (John Wiley & Sons: New York, N.Y., 1997).
FIG. 1 shows a typical CORBA environment 38. A client 40 connects to a server 54 via a network 44 (e.g., via the Internet). A client 42 connects to the server 54 via a network 46 (e.g., via the Internet). A client 50 connects to the server 54 via a network 48 (e.g., via the Internet). CORBA provides local/remote transparency in a distributed object network as shown in FIG. 1 by providing Internet Inter-ORB Protocol (IIOP) services 52. An ORB service represents a standard CORBA service that can broker inter-object calls within a single process, multiple processes running within the same machine, or multiple processes running within different machines that may be across multiple networks and operating systems. For example, the client 42 includes an application that uses client-side stubs to obtain an object reference (e.g., a handle) to a remote CORBA object and to dispatch method invocations to the remote CORBA object. The communication between the client and the server-side object uses the IIOP.
Referring to FIG. 1, the server 54 includes a relational database management systems (RDBMS) 60 (e.g., residing in a storage of the server 54). The server 54 also includes a data service 56, which can be implemented as a collection of CORBA objects, that encapsulates the limited resource, the RDBMS 60. For example, the data service 56 may provide a set of operations that can execute SQL queries, stored procedures, and perform connection management.
Referring to FIG. 1, the data service 56 can be used by standard applications (e.g., a database interface) that reside in the clients 40, 42, and 50. The clients 40, 42, and 50 obtain a handle (e.g., an object reference) to bind to the data service 56. In particular, CORBA's object location mechanism includes the CORBA client stubs which offer a bind mechanism to locate a remote object and obtain an object reference for the remote object. Accordingly, the server 54 provides various services such as the data service 56. The server 54 also includes standard CORBA support services in a CORBA layer 58 for activating the data service 56 and administering the data service 56.
However, the standard CORBA support services do not provide significant client-side encapsulation for requesting a service, efficient workload balancing, a substantial variety of access modes, or robust fault tolerance. Accordingly, an improved method and apparatus for providing a service framework for a distributed object network system is needed.